Date: Sat,  5 Mar 94 04:30:02 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V94 #59
To: tcp-group-digest


TCP-Group Digest            Sat,  5 Mar 94       Volume 94 : Issue   59

Today's Topics:
                              CORE DUMPS
             Food For Thought -- The BBS Network (3 msgs)
                     jnos v1.10 and jnos40 v1.00
                         PA0GRI v2.0p and PPP

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 4 Mar 94 13:50:24 EST
From: "<SPC EDWARD V. QUICKSALL>" <quicke@meade-ams1.army.mil>
Subject: CORE DUMPS
To: tcp-group@ucsd.edu, root@ucsd.edu

ATTN: PLEASE PASS TO SYSTEM ADMINISTRATOR:

     I am the system admin at meade-ams1.  I am getting core dumps from
your host.  I cannot figure out why I am getting them.  Any Assistance
is appreciated.

  

                          SPC Edward V. Quicksall 
                           System Administrator
                               USAISC-MEADE
                        FORT GEO. G. MEADE, MD 20755
                         COMM  (301) 677-1063/1064 
                            DSN  923-1063/1064
                E-Mail Address <quicke@meade-ams1.army.mil>

------------------------------

Date: Thu, 03 Mar 1994 21:30:24 -0600 (CST)
From: Jeffrey Austen <JRA1854@tntech.edu>
Subject: Food For Thought -- The BBS Network
To: tcp-group@ucsd.edu, nos-bbs@hydra.carleton.CA

Here are a few observations on improvements needed to the BBS network.  I
hope that this generates some discussion of these problems which will lead
to solutions.

BBSs have no priority mechanism for distingushing between bulk mail
(bulletins, etc.), normal mail and priority or emergency mail. In an
emergency environment these distinctions must be made and the messages
queued appropriately. There should be a mechanism to forward priority or
emergency mail immediately and to limit the rate of or suspend the
forwarding of normal mail and bulk mail.  Priority designators should be
compatible with or mappable to NTS designators and any other applicable
designators; the mapping should be well defined.  This capability should
be added to the BBS software and should be controllable by remote sysops.

There is a schism between the SMTP (TCP/IP) addressing and the BBS
addressing mechanism: neither form is compatible with the other.
Additionally, some forms of the BBS addresses look too much like Internet
addresses (for example, NA and SA are valid Internet top-level domains). 
This makes it difficult for systems running both BBS and TCP/IP to handle
mail.  The creation of an addressing system which is compatible with the
Internet (and with OSI?) addressing should be explored; if compatiblity is
unobtainable the BBS addressing system should at least coexist with little
confusion and operational difficulties.

Personal messages (one-to-one) and bulletins (one-to-many) are too
interemixed.  There should be a separation of these two functions at the
protocol and addressing level, even if they are combined at the user
interface.  

Bulletins are nearly impossible to manage, especially if one tries to
organize them in some logical fashion.  Standardized names for bulletin
groups should be established with allowances for the addition of local and
regional groups.  MIDs, BIDs, and other IDs need to be clarified and
possibly simplified.  BIDs should be expanded to be compatible with that
used on the Internet so that newsgroups can be gatewayed at multiple
points while avoiding duplication of bulletins.

BBS message interchange protocols are poorly documented.  (This is being
worked on by W0RLI and others.)

Jeff, k9ja
+-+
Jeffrey Austen       |  Tennessee Technological University
jra1854@tntech.edu   |  Box 5004
(615) 372-3485       |  Cookeville Tennessee 38505   U.S.A.

------------------------------

Date: Fri, 04 Mar 94 06:45:00 -0000
From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
Subject: Food For Thought -- The BBS Network
To: tcp-group@UCSD.EDU

Cc: nos-bbs@hydra.carleton.CA
Cc: JRA1854@TNTECH.EDU

In a msg on <Mar 04 03:30>, Jeffrey Austen writes:

 JA> There is a schism between the SMTP (TCP/IP) addressing and the 
 JA> BBS addressing mechanism: neither form is compatible with the 
 JA> other. Additionally, some forms of the BBS addresses look too 
 JA> much like Internet addresses (for example, NA and SA are 
 JA> valid Internet top-level domains). This makes it difficult 
 JA> for systems running both BBS and TCP/IP to handle mail.  The 
 JA> creation of an addressing system which is compatible with 
 JA> the Internet (and with OSI?) addressing should be explored; 
 JA> if compatiblity is unobtainable the BBS addressing system 
 JA> should at least coexist with little confusion and operational 
 JA> difficulties.

Some time ago, I had my head handed to me by Brian Kantor and others for
proposing to treat "BBS" as a top-level pseudo-domain from the point of view of
the Internet, much like the new style "UUCP" addresses.  In other words, a BBS
address such as "KA1AZ.#SORI.RI.USA.NA" would become, in the new system,
"KA1AZ.#SORI.RI.USA.NA.BBS".

The BBS "hierarchical" addressing system is not truly hierarchical, since
addresses are not unique.  That is, "KA1AZ.#SORI.RI.USA.NA" might receive some
mail addressed instead to "KA1AZ.RI.USA.NA", "KA1AZ.RI.USA", or even
"KA1AZ.RI".  The present BBS network considers all of these addresses to be
valid and substantially equivalent, and this would play havoc with attempts to
define mappings from the Internet.  We could make a rule that said that all
"*.BBS" addresses would have to be fully qualified, I suppose, but we should be
prepared to see it widely violated.

Still, any "*.BBS" pseudo-domain address would be strictly hierarchical between
the "BBS" part and the "*" part, and this would allow an Internet machine to
hand the message over to a foreign mail router as is done for "*.UUCP"
pseudo-domain addresses.

-- Mike

------------------------------

Date: Fri, 4 Mar 1994 21:15:47 -0800
From: brian@nothing.ucsd.edu (Brian Kantor)
Subject: Food For Thought -- The BBS Network
To: mikebw@bilow.bilow.uu.ids.net

We didn't ARBITRARILY hand you your head.

I believe that the best scheme proposed so far for integrating the
hambbs world with the Internet is this:

Gateways which move bbs mail into the internet would be responsible for
routing mail back the other way.  That means that if mail from a bbs
were to pass through the W6XYZ gateway, the W6XYZ gateway would list
itself as a mail exchanger for that BBS.

The way this would be done would be that the return address of the BBS
(e.g, From: W6TYP@WB6KDT.#SOCA.CA.USA.NOAM) would be transformed by
the gatewaying system (e.g, WB6CYT.AMPR.ORG) to an internet address
(i.e., From: W6TYP@WB6KDT.AMPR.ORG), and the gateway would verify that
an MX (Mail eXchanger) record for WB6KDT.AMPR.ORG is listed with the
AMPR.ORG nameserver.  It would even be possible to prioritorize the
gateways; the MX preference could be set to 100 + bbs_to_gw_hopcount.

The gateway would be responsible for adding the entry to the nameserver
if one didn't already exist.   Since there are only a limited number of
BBSs in any region around a gateway system, the nameserver would soon be
up to date with the relevant entries.

Additionally, the gatwaying system would be responsible for verifying
that it had sufficient routing information on the ham radio side to
return mail arriving for that BBS - and adding it to its bbs routing
tables if it didn't already.  Again, that's not that large a table,
and it really doesn't grow very fast.

No, no existing piece of code does this today.  But if you're going to
do it right, do it RIGHT!
	- Brian

------------------------------

Date: Fri, 04 Mar 94 03:55:00 MST
From: LL@MHS.Novell.COM
Subject: jnos v1.10 and jnos40 v1.00
To: nos-bbs@hydra.carleton.CA, nos-bbs@hydra.carleton.CA, tcp-group@UCSD.EDU

Form: Reply
Text: (8 lines follow)
Johan, first let me thank you for all your hardwork, we do appreciate it !

Secondly I like the compile you included with the source code it has all the 
right features defined. But I would like to have it compiled for 386 not 
8088.   Do you have a config.h file for the version you compiled ?

Thanks, Lee

Original text: (26 lines follow)
>From INET-5@Inetgate.Novell ("Johan. K. Reinalda"){SMTP:johan@ece.ORST.EDU}, 
on 02-28-94 19:48:
It has just been put on 
ftp.ece.orst.edu, in pub/ham/wg7j/110 and pub/ham/wg7j/jnos40
and
ucsd.edu in hamradio/packet/tcpip/incoming 

Files are
docs110.zip - documentations, example configs etc for jnos and jnos40
jnos110.exe - the executable with the docs110.zip included
jnos110.zip - the sources
jnos4010.zip - the new data engine code.

New documentation, thanks to Doug Thompson, WG0B

Some new feature for 1.10 :
rip2, status window, 'looking' at sockets, new pi driver, color, and
a few little others...



Enjoy, and see some of you at tapr this weekend...

73,
Johan, WG7J.

Use Proportional Font: true
Previous From: INET-5@Inetgate.Novell ("Johan. K. Reinalda"){SMTP:johan@ece.ORST.EDU}
Previous To: INET-3@Inetgate.Novell{SMTP:nos-bbs@hydra.carleton.CA},
 INET-4@Inetgate.Novell{SMTP:tcp-group@UCSD.EDU}
Original to: INET-3@Inetgate.Novell{SMTP:nos-bbs@hydra.carleton.CA},
 INET-4@Inetgate.Novell{SMTP:tcp-group@UCSD.EDU}
Attachment Count: 0

---Begin attached file ATTRIBS.BND.Z---

begin 666 ATTRIBS.BND.Z
M'YV00LKD>>.&# @H8<:L*6,P"!TZ<M*(J4.GS!P COHA^-5! 8"/'P,.+'A0
MSALX$<O0"2,G#P@B859J  D@ DT !  T , JP,V?0#\^B7@FC9LP;$!4Q$,G
ME0 C'H,"T!1@  "GE (( +#U8P:N 'SZ! -T:Q@ 2;K2Q/'O)R2?0)M, 3$E
MC)LY=,M$-".U[]JV-]\&'?*F3DHY?A/_% O@K%D ]_YLU0-9,@!<E;?RR@P 
M'>=TG.=QSA$@\E8ZI2T[2KWU%NO+K].]5O?:@ #3 );<MBQF]]8QO@&0"5XF
M.*;@F8)W"JYJ=V(R84D%"(!D0 !V! ) ,A" !H( V!($X+,@ (@& 8@Y"( &
M0@ &$@+ FA" 2H4 ^"P\#PMN.C#KH!00 " '! "&>$"4=YY/#P0 CGO Q <*
+!0-:8" & 0 Q$P  
 
end

---End attached file ATTRIBS.BND.Z---

------------------------------

Date: Sat, 05 Mar 1994 02:24:18 -0500 (EST)
From: KCALEWINE@delphi.com
Subject: PA0GRI v2.0p and PPP
To: tcp-group@ucsd.edu

To Whom It May Concern:
It's difficult to get information regarding all the different flavors
of NOS, and I m'm not even sure this is the place to look, but I'm going
to give it a shot anyway. What have I got to lose?

Is anyone familiar with Kka9q NOSPA0GRI v2.0 p variant of KA9Q NOS'm looking for information regarding the PA0GRI v2.0p version of
KA9Q NOS. Specifically, even though PPP is specifically mentionedmentioned in the docs,
it does nPPP does not appear to be incliuded in this particular version of
the software. SlipLIP is there, but no PPP.

I am attempting to put together a packet radio to Internet gateway
and my iInternet providerservice provider woulfd "prefer" that I use PPP
over SLIP for the dial-in. In any event, my have an older version of KA9Q NOS
that does havees include PPP, but it doesn't have all the neat bells and
whistles of PA0GRI v2.0p.

Is there a  versionMy I haven't looked for other at other NOS vairriations (JNOS, etc) to see if they,
in fact, include PPP.  

AIs tehrer ere anyone out there that can point me in the right direction.
Any suggestions regarding the establishment of a packet radio to
Internet gateway would be greatly appreciated. Many thanks.

KC Alewine
KCALEWINE@DELPHI.COM
.

------------------------------

Date: Fri, 4 Mar 94 23:07:11 PST
From: enge@almaden.ibm.com
To: TCP-GROUP@UCSD.EDU
Subject: Re: Food For Thought -- The BBS Network
Reply-To: enge@almaden.ibm.com
News-Software: UReply 3.1
References: <01H9JT6UYFTUEZEE05@tntech.edu>

In <01H9JT6UYFTUEZEE05@tntech.edu> Jeffrey Austen <JRA1854@tntech.edu> writes:
>Here are a few observations on improvements needed to the BBS network.  I
>hope that this generates some discussion of these problems which will lead
>to solutions.
>
>BBSs have no priority mechanism for distingushing between bulk mail
>(bulletins, etc.), normal mail and priority or emergency mail. In an
>emergency environment these distinctions must be made and the messages
>queued appropriately. There should be a mechanism to forward priority or
>emergency mail immediately and to limit the rate of or suspend the
>forwarding of normal mail and bulk mail.  Priority designators should be
>compatible with or mappable to NTS designators and any other applicable
>designators; the mapping should be well defined.  This capability should
>be added to the BBS software and should be controllable by remote sysops.

Take a look at the AA4RE BBS software.  It has queueing and an
alternate set of message types for "emergency" mode that can be turned
on and off by remote sysops just as you asked.  These features were
original designed by the Santa Clara Valley ARRL Section ARES after
the 1989 Loma Prieta Earthquake.  Since then, they have been refined
by a series of exercises.  Comments welcome.

>
>There is a schism between the SMTP (TCP/IP) addressing and the BBS
>addressing mechanism: neither form is compatible with the other.
>Additionally, some forms of the BBS addresses look too much like Internet
>addresses (for example, NA and SA are valid Internet top-level domains).
>This makes it difficult for systems running both BBS and TCP/IP to handle
>mail.  The creation of an addressing system which is compatible with the
>Internet (and with OSI?) addressing should be explored; if compatiblity is
>unobtainable the BBS addressing system should at least coexist with little
>confusion and operational difficulties.

I once proposed something like AA4RE@AA4RE.#NOCAL.CA.USA.NOAM.AMPR.ORG.
In fact, the latest versions of the AA4RE BBS will automatically strip
the AMPR.ORG off the end so the user could address his messages with
the extra piece on and the BBS would ignore it.

>
>Bulletins are nearly impossible to manage, especially if one tries to
>organize them in some logical fashion.  Standardized names for bulletin
>groups should be established with allowances for the addition of local and
>regional groups.  MIDs, BIDs, and other IDs need to be clarified and
>possibly simplified.  BIDs should be expanded to be compatible with that
>used on the Internet so that newsgroups can be gatewayed at multiple
>points while avoiding duplication of bulletins.
>

Sounds reasonable.  What is your proposal?

>BBS message interchange protocols are poorly documented.  (This is being
>worked on by W0RLI and others.)

I thought they were fairly well documented but even with great docs,
they are no good if people don't follow them.  There are also too many
quirks like some code failing because there are two lines in a single
packet rather than one.  The other problem is that many authors expand
the protocol without any consultation of their peers to see how to
make things fit.  The concept of an RFC (Request For Comments) seem to
be unheard of.

Roy Engehausen -- AA4RE -- enge@almaden.ibm.com

------------------------------

End of TCP-Group Digest V94 #59
******************************